Update to fix Over and Understimation of Errors#1088
Conversation
|
I am adding to html files with the results of the previous tests I mentioned. Its side by side hit on track and track pz distributions with text columns so you can see exactly how things change. The change is tiny, but I realize because the chi square determines if we do pileUp or not it will change things slightly. It does seem to remove a very small amount of tracks, but it does add more tracks to the momentum FEE peak and the tracks it removes seem to all be in the really low (perhaps out of physics scale) momentum and hit number variety: https://s3df.slac.stanford.edu/people/rodwyer1/chiFix/momentum.html and https://s3df.slac.stanford.edu/people/rodwyer1/chiFix/hitOnTr.html |
|
I will be doing two simple analyses now. I will be removing the portion where I change the amplitude error (just to check that this indeed does nothing) and a chi sqr cut. You will get htmls for these too. After that, I think it is relevant to make a choice as to whether to push this. Tim may want to see how the error changes with time, but I am doing the simplest studies first. |
|
Added the runs without the amplitude err change here: https://s3df.slac.stanford.edu/people/rodwyer1/chiFix/noAmp/hitOnTr.html. Compare it to the left sides of the previous htmls. You can see almost nothing changed (even entry wise) maybe singular track changes. I believe this confirms my hypothesis. Now I will implement a chi cut of .01 |
|
Here is the chi square cut of .01 applied. I need to figure out a way to plot this and without on top of eachother. You can definitely see the loss in efficiency, but I am not sure you make up for it in momenum: https://s3df.slac.stanford.edu/people/rodwyer1/chiFix/withcut/hitOnTr.html |
|
When it removes alot of tracks (i.e. in the second run) it does seem to do so predominantly in good places to do so, i.e. the junk at ~200 MeV. |
|
Okay last study done; here is how the actual errors drift or dont over runs: https://s3df.slac.stanford.edu/people/rodwyer1/chiFix/Errors/hitOnTr.html. It tells you that the strip error from the database (which is not the dsame as the chi square fit found from actually fitting pulses) doesn't drfit, and this is likely because it was insufficiently recorded or not recorded under beam. |
|
I have done layer studies here: https://s3df.slac.stanford.edu/people/rodwyer1/chiFix/LayerChange/hitOnTr.html. You can find a subtraction of the two plots for 14170 here: https://www.desmos.com/calculator/w0ndtdbzud. There is a clear peak near the first 4, and it dies away with later layers. This was expected. |
tracking/src/main/java/org/hps/recon/tracking/ShaperLinearFitAlgorithm.java
Show resolved
Hide resolved
3 participants
This update is directed at getting amplitude errors and chi square values aligned with their proper values as determined by the chi square probability. The chi square probability, when chi is estimated properly, should be a flat distribution by the inverse CDF transform theorem. Under the assumption we have an unknown multiplicative error in our strip error estimation (that is layer dependent), we can plot the chi square probability with a different multiplicative value of error. We can then make a best fit measurement to determine what this factor is and correct it (below is a drawing of what that scan looks like):
When it was fit, this factor was determined to also be run dependent:
So we did a rather long run dependent calibration, and this is the result. If you are interesting in seeing the run dependent histograms of before and after for the chi square fits, they can be found here:https://s3df.slac.stanford.edu/people/rodwyer1/chiFix/master.html.
You can see that the runs do seem to flatten the chi out. Under the assumption that the error is multiplicatively scaled, this same factor is applied to the amplitudeErrors. This should, in all likely hood, affect almost nothing. I have been working with the reconstruction for a couple of years, and have never seen these used for anything but diagnostics. Still, there are a few tests we may want to employ. The first is that this change seems to motivate in the foremost layers a chi sqr cut at .01 to remove a spike in bad fits. These are not consitent with underestimating errors now; these are genuinely poor fits and removing them should clean things. That needs to be done and a simple evaluation of track number and moller peaks should be checked. Others (particularly those who can do the Moller stuff) may need to help with this. The other test that should be done is to plot the actual strip error (which is another number which should be related to these values but may not be if the way the database errors are logged were wrong) and diagnose the issue that caused this. This shouldn't prevent the proposed changes from being pushed, but its the next plot I will append to this request.